An operating system is a program that controls the allocation of processing and other resources in a computer. The operating system also controls the execution of application programs and provides utility functions such as file system management and network connectivity. Network connectivity is usually provided by a “protocol stack”. Significant strategic planning and specification of the individual functional modules included in the operating system precede development and deployment. This is due in part to the complex nature of an operating system.
Another significant factor in the design and development of an operating system and the care taken in planning and specifying the individual functional modules contained therein is the reliance by third party developers on operating system specifications. For example, many hardware components are developed by companies that do not have any interaction whatsoever with the entity that develops and markets an operating system. These hardware manufacturers need to create software drivers that enable the operating system to use the hardware component. Still other companies develop specialized network protocol stack components. All of these third-party developed functional modules remain compatible with the operating system—thanks to the stability and reliability of the operating system specifications promulgated by the operating system's maker.
Because so much effort is required to qualify a new embodiment of a protocol layer, and partly because of the need to provide specification stability to a community of third party developers, independence is an important design objective. For any embodiment, hardware or software, of a protocol layer that is included with or intended to operate in conjunction with the operating system, independence in design ensures that new embodiments designed in accordance with an operating system specification or in accordance with the functionality specified by a particular layer in the network protocol will work and play well with others.
A protocol stack is, in essence, a collection of functional protocol layers that implement a network protocol. A data packet, which is one example of a quantum of data, is typically encapsulated in a protocol message. The protocol message is used to convey the data packet from one protocol layer to the next. As the data packet is processed by succeeding protocol layers, the size of the protocol message increases such that it becomes burdensome for a receiving protocol layer to extract the data packet from the protocol message. And, many processing directives, known as packet processing information, need to be extracted from the protocol message as well. In order to reduce some of the burden in extracting this packet processing information, one example embodiment of a protocol stack supports the conveyance of packet processing information from one protocol layer to another outside of the normal channel (i.e. outside of the protocol message). This alternative conveyance mechanism is known as out-of-packet communications.
A technique has been developed for enabling an embodiment of a first protocol layer to determine what type of packet processing information an embodiment of a protocol layer is able to provide. This technique is called option negotiations. A good example of this technique is employed by one example embodiment of a Data Link Layer. According to this example embodiment, the Data Link Layer may discover that a hardware driver (an embodiment of the Physical Layer) is capable of providing a checksum for a data packet received from the computer network. Hence, the Data Link Layer can determine that a checksum is available from the driver. By using the checksum provided by the driver, the embodiment of the Data Link Layer is able to avoid an independent checksum calculation, thus saving processing resources (in a software embodiment).
Once the option negotiation between embodiments of two protocol layers is complete, a template for communicating out-of-packet data between the two embodiments is selected. This template is selected based on the capabilities of the embodiments of the two protocol layers at the time they are both designed. So long as the embodiments of both protocol layers are designed and developed in cooperation with each other (e.g. the two protocol layer embodiments result from the collaborative efforts of two design groups), the notion of using a static template that defines the composition of any out-of-packet data remains viable. This type of collaboration amongst design groups in the design phase of a product is somewhat contrary to the notion of design independence. Collaboration amongst design groups is often required to achieve stability and accuracy in design specifications. But once the specifications are reliable, embodiments of two protocol layers should interact correctly without collaboration in the design phase so long as the embodiments adhere to the specifications.
It is difficult to encourage, let alone enforce such collaborative efforts. As noted earlier, many third party developers develop drivers for unique hardware devices. Still other companies develop specialized embodiments of one or more layers of a protocol stack. And, in light of networking protocol evolution, it is difficult to define stable out-of-packet templates for layers of a protocol stack even amongst design groups in a single company (e.g. design groups engaged by the operating system's maker).